Auto merge of #4006 - mcgoo:cargo_test_dylib, r=alexcrichton
authorbors <bors@rust-lang.org>
Tue, 9 May 2017 17:15:40 +0000 (17:15 +0000)
committerbors <bors@rust-lang.org>
Tue, 9 May 2017 17:15:40 +0000 (17:15 +0000)
commit80f19a8e240577d90caf38503bb3034ac7dd630d
tree2afbdf2f564fe3540f5813679ca0bd8ac3b40ea9
parentcf17c9f7118f544ec304ed6f50d92b3759487123
parentd773d7bb9391f1bdab442a070235ac2acb4adbb3
Auto merge of #4006 - mcgoo:cargo_test_dylib, r=alexcrichton

fix `cargo test` of dylib projects for end user runs too

Fixes running `cargo test` and `cargo test --target <target>` for dylib projects.

Moves the logic just landed in https://github.com/rust-lang/cargo/pull/3996 into cargo itself, so cargo sets the dylib path for anyone running `cargo test` or `cargo run`. Current master sets the dylib path only for  `cargo test` on cargo itself.

This PR pins to rustup 1.2.0 for the purposes of testing. If https://github.com/rust-lang-nursery/rustup.rs/pull/1093 ends up working out, then this PR would only be important for non-rustup users and people doing cross testing, `cargo test --target <target>`.

Arguably https://github.com/mcgoo/cargo/blob/ed273851f8bc76f726eda4a2e2a7bb470c3718bc/src/cargo/ops/cargo_rustc/context.rs#L249-L253 should point to lib/rustlib/\<host triple\>/lib instead of sysroot/lib, because I think if the libs are different, you will never be able to compile a working plugin anyway, and for the host=target case you get the  lib/rustlib/\<host triple\>/lib anyhow. Is there ever a case where the lib/rustlib/\<host triple\>/lib and sysroot/lib versions of the libs would be expected to differ?

This is not a huge deal for me one way or the other - it doesn't impact my workflow at all. I nearly dropped it when I saw @alexcrichton had made it all work in 3996, but I think it's worth doing because it removes a surprise. It certainly would have saved me a couple of days of confusion. Either way, thanks for looking it over.
src/cargo/ops/cargo_rustc/compilation.rs
src/cargo/ops/cargo_rustc/context.rs